% !TEX root = main.tex

\section{Model Driven Security}
\label{sec:mds}

This section starts by analyzing the concept of \mds from the literature in order to propose a newer and more accurate definition. 
It then synthesizes a generic schema, the \emph{Y-Model}, which is an incarnation of this definition and used to evaluate modeling and security analysis capabilities of various \mds methodologies later in \sect \ref{sec:evaluation}.

\subsection{Concept}
\label{sec:concept}

Several contributions \cite{sanchez:jucs-15-15,gartner:mds,citeulike:10644974,Basin:2011:DMS:1998441.1998443} provided tentative definitions for \emph{Model Driven Security}. 
In this section, we analyze their proposals to extract their common features and propose a more accurate definition that encompasses the previous ones.

S\'anchez \etal \cite{sanchez:jucs-15-15} emphasized very early the \emph{de facto} necessity of introducing models as primary artifacts for \mds. 
McDonald \cite{gartner:mds} promoted in 2007 the use of Domain-Specific Models (\textsc{Dsm}s) for each concern, business and security, and introduced the idea of Separation of Concerns (SoC). 
Not longer after, Lang and Schreiner \cite{citeulike:10644974} introduced the idea of using models (and \textsc{Dsm}s in particular) at each stage of the development, 
but more importantly the systematic use of transformations for generating code from these high-level specification in an automated way, to avoid error-prone human intervention. 
These transformations take care of the runtime security management and policy enforcement. 
More recently, Basin \etal \cite{Basin:2011:DMS:1998441.1998443} insisted on the importance of visual tools and automated transformations to generate appropriate code, 
which constitute the very core concepts of \textsc{Dsm}s. They also conveyed the strong idea that \mds is no more than a specialization of the \mde approach with the systematic use of \textsc{Dsm}s. 



% Definitions
%\emph{Model Driven Security} (\mds) is an emerging concept in the last decade since the introduction of Model-Driven Engineering (\mde).
%An intuitive question regarding this concept is what is exact \mds and its general goal.
%For example, in \cite{5560678} Huang and Kirchner use Coloured Petri Net to modularize security concerns and verify security properties, \eg completeness, integrity, \etc; 
%in \cite{10.1109/WORDS.2005.11} Shafiq \etal manage to develop concurrent \rbac (Role-Based Access Control) formalism for expressing access control policies in real-time systems; 
%and in \cite{Xu:2012:MAA:2295136.2295173} Xu \etal apply models to generate tests for security-intensive system. 
%These proposals are all \emph{model-based} approaches to deal with security issues. Can we call these model-based approaches \mds?
%To answer this question, we first explore and quickly discuss some classical definitions for the concept \mds in the literature.
%
%\jackin{This part can be reduced finally, according to the space needed for the paper.}
%
%S\'anchez \etal insisted on ``\emph{how Model-Driven Development should be
%specialized in order to deal with security aspects} \cite{sanchez:jucs-15-15}'',
%which emphasizes the \emph{de facto} necessity of models for \mds. However,
%their statement is not an explicit definition but their overview of
%understanding of \mds, which is too general to make \mds distinguishable from
%other security-related terms involving the use of models.
%
%McDonald introduced in 2007 the key idea of separating business from security
%concerns: ``\emph{the use of visual models or domain specific modeling languages
%during application design, development and composition to represent and assign
%security primitives - such as confidentiality, integrity, authentication,
%authorization and auditing - to application, process and information flows
%independent of the specific security enforcement mechanisms used at runtime}. \cite{gartner:mds}''
%
%Not longer after, Lang and Schreiner introduced the necessity of using
%Domain-Specific Languages (\DSL) for capturing requirements at higher levels of
%abstraction, and generating code automatically: they view \mds as ``\emph{the
%tool-supported process of modeling security requirements at a high level of
%abstraction, and using other information sources available about the system
%(produced by other stakeholders). These inputs, which are expressed in Domain
%Specific Languages, are then transformed into enforceable security rules with as
%little human intervention as possible. \mds explicitly also includes the
%run-time security management (\eg entitlements / authorizations), \ie run-time
%enforcement of the policy on the protected IT systems, dynamic policy updates
%and the monitoring of policy violations.} \cite{citeulike:10644974}'' They also
%highlighted the necessity of supporting these security engineering phases by appropriate
%tools.
%
%More recently, Basin \etal insisted on the importance of visual tools and
%automated transformations to generate appropriate code, ideas that constitute
%the core of \DSL:  ``\emph{In model-driven development, system designs are
%specified using graphical modeling languages like UML and system artifacts such
%as code and configuration data are automatically generated from the models.
%Model-driven security is a specialization of this paradigm, where
%system designs are modeled together with their security requirements and
%security infrastructures are directly generated from the models.} \cite{Basin:2011:DMS:1998441.1998443}''

% Characteristics
Although different points of view are expressed in the above contributions, they share common features that constitute significant characteristics for \mds: \emph{separating security from business concerns} at the very beginning of the development lifecycle to enable reusable and cleaner design; \emph{using \textsc{Dsm}s} for both concerns to benefit from associated advantages (adequate levels of abstraction closer to both concerns; concrete syntaxes with visual representations; automatic transformations enabling trustful code, among others); \emph{integrating security and business concerns} by means of model composition / weaving, using transformations, which enables analysis of security enforcement before generating low-level code; \emph{enforcing security at runtime} directly from the integrated model in an automated fashion; and finally \emph{assisting development with appropriate tools} at each step of the development.


%\begin{description}
	%\item[Separate security from business concerns] as much as possible at the beginning of software development lifecycle, to enable reusable and cleaner design;
	%\item[Model security concerns using DSL] to benefit from associated advantages: higher levels of abstraction closer to the security domain; concrete syntaxes with visual representations; automatic transformations enabling trustful code, among others;
	%\item[Integrate security and business concerns] by means of model composition/weaving, possibly using transformation technologies, for verification of security enforcement and further low-level infrastructure-generation;
	%\item[Enforce security at runtime] directly from the integrated model with as little human intervention as possible.
	%\item[Support the development with capable tools] to help experts at each step of their work. 
%\end{description}
From those common features, it is possible to propose a new definition that encompasses the previous ones by including the previous characteristics:
\begin{quotation}
\textbf{Model Driven Security} is a tool-supported model-driven approach that separates security concerns from business logic at early stage of the development lifecycle, specifies business and security models respectively with \textsc{Dsl}s, and manages the secure infrastructure generation directly from a composed model with as little human interference as possible.
\end{quotation}

% Outline: Y-Model as generic evolution criteria
\subsection{Y-Model: A Generic Evaluation Schema for MDS}
\label{sec:Y-model}

\begin{figure}[t] 
	\centering
	\includegraphics[width=\textwidth]{./figures/Y-model}
	\caption{Y-Model: a generic evaluation schema for Model Driven Security}
	\label{fig:y-model}
\end{figure}

Inspired from the well-known V-Model in software engineering, we propose a \emph{Y-Model} as a general evaluation schema for \mds methodologies.
It is named so because it is shaped as the letter ``Y''.
Note that, although other proposals, \eg \cite{Capretz:2005}, mention the Y-Model in their research, our proposal is, 
to the best of our knowledge, the first one to mention this concept in the context of \mds.

The proposed Y-Model is a foundational concept model for \mds and fully integrates \mds characteristics presented in \sect \ref{sec:concept}.
It bridges the semantic gap between high-level security concerns and their enforcement on system infrastructure \cite{vanWyk:2005:BGS:1092708.1092755}.
It illustrates the complete process of \mds as well as the general objective of \mds that the runtime infrastructure with security concerns enforced is
obtained from high-level requirements based on model-driven architecture.
The Y-Model is organized in three layers, as depicted in \fig \ref{fig:y-model}.
%\jackin{The remaining part of this section can also be reduced.}

\subsubsection{Layer 1: Requirement Gathering}
\label{sec:Y-L1}

This top layer is the key to SoC: business logic is handled by software engineers and domain experts, is organically separated from security concerns that are delegated to security experts. 

%corresponds to the classical requirement analysis phase in
%software development lifecycle. However, here we clearly separate business
%logic, handled by software engineers, from security concerns, delegated to
%security experts. In such way, domain experts and software engineers can focus
%on the business, and security experts can perform security-related tasks,
%including design and verification, without considering business logic details as
%well as implementation requirements regarding a specific platform.

\subsubsection{Layer 2: Modeling \& Analysis}
\label{sec:Y-L2}

The second and middle layer deals with modeling and analysis tasks: each model, conforming to a different metamodel, is extracted independently from the requirements expressed at the previous layer. Since both are loosely coupled, each side can perform analysis tasks tailored to the domain at hand, in an agile fashion: from the verification
results, models are evolved and corrected until satisfactory models are reached.

Both models are then composed, conforming to a \emph{composition metamodel} that merges information from business and security. It can take several forms: profiling \UML-based business metamodels to integrate security information; building a mapping metamodel between both metamodels to link concepts from both sides; or creating a truly composed metamodel with concepts from both sides. The possibilities are diverse, 
and we discuss later in \sect \ref{sec:evaluation} how each evaluated \mds methodology performs its own.

Once the composed model is obtained, integration verification can be performed to ensure enforcement of security properties, very similarly to system integration testing. 
%At this stage, the composed model can still be corrected w.r.t. integration verification results, and even allow reflecting the flaws discovered to the previous layer and later recompose them via automated transformations.

 %domain and
%security experts extract models from the requirements expressed in the previous
%layer, separately from each others. Generally, each model conforms to a
%different metamodel tailored for the task at hand, thus favoring loose coupling
%between business and security models. Furthermore, each side can perform
%verification to validate models in an agile style: from the verification
%results, models are evolved and corrected until satisfactory models are reached.
%
%Since models are separated, it is necessary to merge them eventually. The
%composition model conforms to a composed metamodel that makes use of the business
%and the security metamodel, but already takes into account platform-specific
%information. However, depending on the choices for those metamodels, the
%composition metamodel can have several forms: profiling \UML-based business
%metamodels to integrate security information; building a mapping metamodel
%between both metamodels to link concepts from both sides; or creating a truly
%composed metamodel with concepts from both sides. The possibilities are
%numerous, and we discuss in Sec. \ref{sec:y-process} how each reviewed \mds methodology
%performs its own.

%After the composed model is obtained, integration verification can be performed
%to check whether security properties are correctly enforced, similarly to
%``system integration testing'' in software engineering. At this stage, it is
%still possible to make the composed model evolve according to the integration
%verification results, or even reflecting necessary corrections to the original
%business and security models and later recompose them.

\subsubsection{Layer 3: Code Generation \& Testing}
\label{sec:Y-L3}

The bottom layer handles code-generation and testing from the composed
model. Two dimensions have to be taken care of: including platform-specific
information, and generating an infrastructure that actually enforces security.
For these purposes, transformation techniques inherited from \textsc{Mde} in general, and \mda in particular, can help reduce the technical
burden. \emph{Model-To-Model} (M2M) helps in this context for integrating platform-specific information seamlessly and still dealing with high-level models (similarly to \textsc{Mda}, this also requires models describing the different targeted platforms). \emph{Model-To-Text/Model-To-Code} (M2C) transformations allow generating code runnable on specific platforms from higher-level description models. In our context, this code integrates the runtime security enforcement infrastructure to deliver a fully executable code. \emph{Model-To-Test} (M2T) transformations aim at generating tests directly from the model, similarly to the test-driven approach: tests are automatically built at the same time as the code to be tested is generated.


%\begin{description}
%\item[\emph{Model-To-Model} (M2M)] transformations consist in transforming
%models into models, which is helpful in this context to integrate
%platform-specific information seamlessly and still dealing with high-level
%models. Similar to the \mda approach (\emph{cf.} \sect \ref{sec:Y-MDA} for a complete
%description), this requires models that describes the different targeted
%platforms.
%\item[\emph{Model-To-Text/Model-To-Code} (M2C)] trans\-for\-ma\-tions consist
%in generating code runnable on a specific platform from higher-level description
%models. In our context, the generated code takes into account a runtime security
%enforcement infrastructure to obtain a fully executable code on the targeted
%platform.
%\item[\emph{Model-To-Test} (M2T)] transformations aim at generating tests
%directly from the model, similarly to the test-driven approach: tests are
%automatically built at the same time as the code to be tested is generated.
%\end{description}

Using transformations automates the task of generating code, enables reuse, and
increases confidence in the generated code since the transformations can be
written once and for all after the metamodels have reached stability. Therefore,
we evaluate in \sect \ref{sec:evaluation} how each approach handles code and
test generation from the models manipulated at higher layers.

\subsubsection{Traceability}
\label{sec:Y-Traceability}

On the very right of Fig. \ref{fig:y-model}, an arrow labeled ``Traceability''
spans over all three layers. Layers 2 and 3 both contain analysis phases that
provide information about the correctness of the involved artifacts: in Layer 2,
the manipulated artifacts are models, which enable exhaustive verification
because the information is still at high levels of abstractions; whereas in
Layer 3, testing is usually used when the entire code for a specific platform is
available (although traditional verification techniques can still be applied,
but are more difficult to settle in this context).

% This paragraph can be cut if we need more space for acknowledgement
Usually, these phases provide information relevant to the concerned layers they
take place into. However, it can be useful to take advantage of this analysis
feedback to reflect their results into higher layers: for example, when mistakes
are detected in the composed model in Layer 2, security or business models can
be corrected accordingly, and requirements can even be impacted by these
modifications.

This backward traceability feature in our Y-Model is seen as a desirable
situation to reach, not as something already possible. As a matter of fact, this
traceability is usually done manually, since automating it is nearly impossible
due to the semantic gaps between layers: for example, the composed model
integrates both business and security models, but also platform-specific
information that makes difficult to trace back mistakes in the security
requirements. Discovering errors in Layer 3 is even worst, since there, security
concerns can be distributed all over the generated code due to its low-level
nature.

\subsubsection{From MDA to the Y-Model}
\label{sec:Y-MDA}

\begin{figure}[t] \centering
\includegraphics[width=0.6\textwidth]{./figures/mda-mds_v02}
	\caption{Y-Model: a specialization of Model Driven Architecture regarding security}
	\label{fig:mda-mds}
\end{figure}

The \mda is an effort of the \omg to standardize model definitions, and favor model exchange and compatibility \cite{omg/2003-06-01}. It promotes a clear \emph{vertical} separation: system's specifications are defined independently from low-level details relevant only for code running on a specific platform \cite{omg/2003-06-01}. As depicted in \fig \ref{fig:mda-mds} (left), the \mda also separates requirement gathering, modeling and analysis, and code generation and testing. As already claimed by previous authors \cite{Basin:2011:DMS:1998441.1998443,10.1109/ARES.2011.110}, \mds  directly inherits from this vertical process. 

However, our Y-Model enriches the higher layer of requirement gathering by clearly separating business and security concerns. \fig \ref{fig:mda-mds} makes this relationship explicit by binding \mds principles with the \mda vertical process: business and security requirements naturally map to Computation Independent Model (\textsc{Cim}); Platform Independent Models (\textsc{Pim}) corresponds in our Y-Model to the composed model resulting from the models obtained from requirements; finally, Platform
Specific Models (\textsc{Psm}) and system infrastructure map to the generated code from the composed model.





%
%After Model-Driven Engineering gained more attention in the software development
%community, several approaches were developed. The \mda is an effort of the \omg
%to standardize model definitions, and favor model exchange and compatibility
%\cite{omg/2003-06-01}. \mda is heavily based on \UML, which was already
%standardized, and well-accepted as a notation for describing object-oriented and
%model-based systems. Systems architectures are organized in a vertical process:
%``\emph{Model-Driven Architecture starts with the well-known and long
%established idea of separating the specification of the operation of a system
%from the details of the way that system uses the capabilities of its platform}''
%\cite{omg/2003-06-01}.
%
%Figure \ref{fig:mda-mds} (left) depicts this process: requirements are collected
%in a Computation Independent Model (\textsc{Cim}), independently of how the
%system will be ultimately implemented; then, a Platform Independent Model
%(\textsc{Pim}) describes the design and analysis of all system parts,
%independently of any technical consideration about the final execution platforms
%and their embedded technologies; finally, these are refined into Platform
%Specific Models (\textsc{Psm}) by integrating platform-specific information 
%to generate platform-specific code using model transformations.
%The \mda process is described in the left side of Fig. \ref{fig:mda-mds}.
%
%As already claimed by previous authors
%\cite{Basin:2011:DMS:1998441.1998443}\cite{10.1109/ARES.2011.110}, \mds directly
%inherits from this vertical process for separating high-level requirements from
%low-level details which guide platform-specific code generation. However, our
%Y-Model enriches the higher layer of requirement gathering by clearly separating
%business and security concerns. Figure \ref{fig:mda-mds} makes this relationship
%explicit by binding \mds principles with the \mda vertical process: business and
%security requirements naturally map to \textsc{Cim}; \textsc{Pim} corresponds in
%our Y-Model to the composed model resulting from the models obtained from
%requirements; finally, \textsc{Psm} and system infrastructure map to the
%generated code from the composed model.
